|
|
|
|
|
|
|
describing the scenarios for which the pattern applies. When possible, detail the participating objects and their interactions. Most importantly, explain what motivated you to come up with the pattern in the first place. |
|
|
|
|
|
|
|
|
Applying the Design Pattern |
|
|
|
|
|
|
|
|
For any subsystem, you should only apply design patterns when you've discovered a recurring problem that needs a reusable solution. The design pattern itself should be abstract so that you can implement it easily in more than one subsystem or component, which might experience the same problem in different ways. For instance, revisiting the factory example from Day 3, the AccountCreator factory class, when abstracted, can be used for different families of bank products, including checking accounts, savings accounts, capital investment accounts, personal loan accounts, commercial loan products, and so on. |
|
|
|
|
|
|
|
|
A good design pattern should be described in basic terms so that there's general reference to a family of related problems. In a subsystem, there's a way that the objects work together to solve a problem through fulfilling a service based upon an operation the subsystem implements for a client. On Day 3, you called the Factory design pattern's class AccountCreator. This name leaves room to solve the problem of creating accounts for the various families of bank products. Thus, you should view a design pattern as a template that describes a problem, provides a solution, and lists the consequences that result from implementing the solution both at a business level and at a technical (for example, memory requirements) level. |
|
|
|
|
|
|
|
|
As mentioned in the preceding section, providing a design solution to a problem leads to certain consequences. At a business level, the consequence is that some valuable service is fulfilled effectively, such as the creation of a bank product or the implementation of a telecommunications switch. At a technical level, the implementation of a design pattern can lead to increased resource consumption. However, the trade-off here is that you get better organized code that is easily reusable and can be evolved over time as the customer's needs change. |
|
|
|
|
|
|
|
|
How to Use and Reuse Design Patterns for Subsystems |
|
|
|
|
|
|
|
|
The chief benefit of using design patterns is to reduce all implementation dependencies between subsystems and components. Subsystem interface classes provide this |
|
|
|
|
|